The year 2016, which is about to end, has been full of work and contributions to the FLOSS comunity. Most of my focus goes to two important projects: Debian and Netfilter. This is no coincidence, since my main interests in the IT world are systems and networks. Some numbers (no exhaustive count):

• Netfilter patches/commits: ~60 contributions
• Netfilter docs/wiki: ~20 contributions
• Debian patches/commits: ~200 contributions
• Debian package uploads: ~30 uploads (also some sponsored uploads)
• Debian package maintenance: ~10 packages
• Number of non-technical people migrated to linux: 2!!

I would like to note that most of my work is done in my spare time, and nobody is paying for it (with the exeption of the Suricata debian package). My expectation for 2017 is to continue in this line, learn more and increment the quality of my contributions. I m especially proud of the the non-technical people who migrated to desktop linux due to my help. I m targeting 2 or 3 more friends and relatives for 2017. So, goodbye 2016! Exciting 2017 ahead.

There are about 15 Netfilter packages in Debian, and they are maintained by separate people. Yersterday, I contacted the maintainers of the main packages to propose the creation of a pkg-netfilter team to maintain all the packages together. The benefits of maintaining packages in a team is already known to all, and I would expect to rise the overall quality of the packages due to this movement. By now, the involved packages and maintainers are:

• maintained or co-maintained by Laurence J. Lane:
  • iptables
  • nfacct
  • libnetfilter-acct
• maintained by Chris Boot:
  • ulogd2
• maintained or co-maintained by Alexander Wirt:
  • conntrack-tools
  • libnetfilter-conntrack
  • libnetfilter-cthelper
  • libnetfilter-cttimeout
  • libnetfilter-log
  • libnetfilter-queue
  • libnfnetlink
• maintained or co-maintained by Neutron Soutmun:
  • ipset
  • libmnl
• maintained or co-maintained by Anibal Monsalve Salazar:
  • libmnl
• maintained or co-maintained by myself:
  • iptables
  • nftables
  • libnftnl
  • conntrack-tools
  • libnetfilter-conntrack

We should probably ping Jochen Friedrich as well who maintains arptables and ebtables. Also, there are some other non-official Netfilter packages, like iptables-persistent. I m undecided to what to do with them, as my primary impulse is to only put in the team upstream packages. Given the release of Stretch is just some months ahead, the creation of this packaging team will happen after the release, so we don t have any hurry moving things now.

Last week we had an interesting Debian meeting in Seville, Spain. This has been the third time (in recent years) the local community meets around Debian. We met at about 20:00 at Rompemoldes, a crafts creation space. There we had a very nice dinner while talking about Debian and FLOSS. The dinner was sponsored by the Plan4D assosiation. The event was joined by almost 20 people which different relations to Debian:

• Debian users
• DDs
• Debian contributors
• General FLOSS interested people

I would like to thank all the attendants and Pablo Neira from Plan4D for the organization. I had to leave the event after 3.5 hours of great talking and networking, but the rest of the people stayed there. The climate was really good :-) Looking forward to another meeting in upcomings times! Header picture by Ana Rey.

The following contributors got their Debian Developer accounts in the last two months:

• Adriano Rafael Gomes (adrianorg)
• Arturo Borrero Gonz lez (arturo)
• Sandro Knau (hefee)

The following contributors were added as Debian Maintainers in the last two months:

• Abhijith PA
• Mo Zhou
• V ctor Cuadrado Juan
• Zygmunt Bazyli Krynicki
• Robert Haist
• Sunil Mohan Adapa
• Elena Grandi
• Eric Heintzmann
• Dylan A ssi
• Daniel Shahaf
• Samuel Henrique
• Kai-Chung Yan
• Tino Mettler

Congratulations!

The next Debian stable release is codenamed Stretch, which I would expect to be released in less than a year. The Netfilter Project has been developing nftables for years now, and the status of the framework has been improved to a good point: it s ready for wide usage and adoption, even in high-demand production environments. The last released version of nft was 0.6, and the Debian package was updated just a day after Netfilter announced it. With the 0.6 version the software framework reached a good state of maturity, and I myself encourage users to migrate from iptables to nftables. In case you don t know about nftables yet, here is a quick reference:

• it s the tool/framework meant to replace iptables (also ip6tables, arptables and ebtables)
• it integrates advanced structures which allow to arrange your ruleset for optimal performance
• all the system is more configurable than in iptables
• the syntax is much better than in iptables
• several actions in a single rule
• simplified IPv4/IPv6 dual stack
• less kernel updates required
• great support for incremental, dynamic and atomic ruleset updates

To run nftables in Debian Stretch you need several components:

1. nft: the command line interface
2. libnftnl: the nftables-netlink library
3. linux kernel: a least 4.7 is recommended

A simple aptitude run will put your system ready to go, out of the box, with nftables: Once installed, you can start using the nft command: A good starting point is to copy a simple workstation firewall configuration: And load it: Your nftables ruleset is now firewalling your network: Several examples can be found at /usr/share/doc/nftables/examples/. A simple systemd service is included to load your ruleset at boot time, which is disabled by default. If you are running Debian Jessie and want to give a try, you can use nftables from jessie-backports. If you want to migrate your ruleset from iptables to nftables, good news. There are some tools in place to help in the task of translating from iptables to nftables, but that doesn t belong to this post :-) The nano editor includes nft syntax highlighting. What are you waiting for to use nftables?

The moment has come. You may contact me now at arturo@debian.org :-) After almost 6 months of tough NM process, the waiting is over. I have achieved the goal I set to myself back in 2011: become Debian Developer. This is a professional and personal victory. I would like to mention many people who have been important for this to happen. But they all know, no need to create a list here. Thanks! This weekend I was doing some hiking in the mountains and had no internet conection at all. When I arrived back home, I discovered an email from Debian System Administrators on behalf of The Debian New Maintainer Team, in which they let me know that my official DD account had been created. During the last 6 month I have been trying to imagine the moment in which the process is finally completed (yes, I have been a bit impatient). At the end, the magical moment in the mountains was followed by the joy of the DD account. Curious how things happen sometimes. Here is a pic of this mountain day, with my adventure friends. I am the first from the left.

People keep ignoring the status of the Pacemaker HA stack in Debian Jessie. Most people think that they should stick to Debian Wheezy. Why does this happen? Perhaps little or none publicity of the situation. Since some time now, Debian contains a Pacemaker stack which is ready to use in both Debian Jessie and in Debian Stretch. Anyway, let s see what we have so far:

1. The pacemaker stack was updated in Debian unstable around Feb 2016.
2. They migrated to Debian testing by that time as well.
3. Most of the key packages were backported to jessie-backports (if not all).
4. Therefore, Stretch is ready for the HA stack, and so is Jessie (using backports).

The packages I m refering to are those which I consider the key components of the stack, and by the time of this blogpost, the versions are:

package	jessie-backports	stretch	sid	upstream
corosync	2.3.6	2.3.6	2.3.6	2.4.1
pacemaker	1.1.14	1.1.15	1.1.15	1.1.15
crmsh	2.2.0	2.2.1	2.2.1	2.4.1
libqb	1.0	1.0	1.0	1.0

How can you check this by yourself? Here some pointers:

• Debian HA packaging team overview: link
• Package tracker for corosync: link
• Package tracker for pacemaker: link
• Package tracker for crmsh: link
• Package tracker for libqb: link

I m sure we even have the chance to improve a bit the packages before the release of stretch. There are some packages which are a bit behind the upstream version. In any case: Yes! you can move from Debian Wheezy to Debian Jessie!

This blog has finally moved away from blogger to jekyll, also changing the hosting and the domain. No new content will be published here.

New coordinates:

• name: ral-arturo.org
• hosting: github pages
• technology: jekyllrb

This year, I mentored a student in Google Summer of Code 2016. I have been involved as a mentor in the Netfilter project, working with nftables and the translation layer between iptables and nft. The nftables framework is ready to use. I myself plan to deploy several production firewalls during upcoming months. Google just send me some goodies, a tshirt and a sticker. Thanks! :-)

Finally, I decided it was time to switch from blogger to jekyllrb hosted at github pages. My old blog at http://ral-arturo.blogspot.com.es will still be online as an archive, since I don t plan to migrate the content from there to here.

There has been some discussion [0] around my decision to drop sysvinit support in the conntrackd package in Debian [1] (version 1:1.4.4-2).

The rationale I used for such a movement was sent to the debian-devel [2] mailing list, and here it is:

• the default init system in debian is systemd
• I don't have any sysvinit system to keep sysvinit files under any kind of maintenance
• sysvinit conntrackd script is really poor, to reliably use conntrackd as a system daemon you should use systemd
• conntrackd & systemd are very good integrated (using libsystemd)
• systemd is starting to drop support for some sysvinit mechanisms [3]
• it's time to let sysvinit die

Lots of people have talked to me with both support and disagreement with the change.

Before reading the rest of this blogpost, please note that I'm not interested in the 'systemd vs sysvinit' war, and starting now I will focus mainly on the subject of building a firewall cluster with netfilter technology and the reasons why I think sysvinit here is irrelevant.

I started working with firewall clusters by the time of Debian Squeeze. By then, I used only sysvinit, because it was the Debian default init system and because I did not dive so much in the internals of the firewall cluster itself.

By then, the conntrackd debian package included support for sysvinit by means of two files (the two files that I dropped in 1:1.4.4-2) :

• /etc/init.d/conntrackd
• /etc/default/conntrackd

Using both files, you could start/stop conntrackd, and nothing more (for example, a proper status check was not implemented).

The conntrackd daemon is used in HA firewall clusters to replicate connection states between nodes of the cluster, so flow states are known in all nodes and they can properly perform stateful firewalling.

When you build HA clusters, there are 2 basic states of the cluster you may check and adjust: failover and failback.

With conntrackd, the failover situation is straight forward: the other node has the state information already from the dying node.
The failback situation is different: depending on the configuration of both the cluster and conntrackd, the new node may ask for a complete synchronisation to the other node when it become alive again (at boot time, for example) . This is the case if you are building a multi-master firewall cluster (i.e: both nodes are seeing traffic and filtering at the same time).

Asking for a complete synchronisation is done by means of a new instance of conntrackd, which communicates using a UNIX socket to the main conntrackd daemon (the one which is actually communicating with the other node). A failback boot procedure may look like this:

1. system boots
2. firewall ruleset loading
3. networking up
4. conntrackd up (main sync daemon: using 'conntrackd -d'; UNIX socket is opened)
5. request sync with other node (using conntrackd -n' which uses the UNIX socket opened in step 4)

In both sysvinit and systemd cases, the step 5 may be implemented using another dummy service which performs the required operations and that depends on the main service representing the step 4.

The point here is that steps 4 and 5 suffer a very bad race condition: the conntrackd daemon may open the UNIX socket (step 4) *after* the we try to use it (step 5).

As you could probably imagine, this is the worst possible scenario: as one of the nodes of the cluster is missing important flow state information the stateful firewall will drop packets and all the network monitoring alarms will start to ring... Ironically, just after a failback operation, when all of our cluster is supposed to be up an running.

To avoid the race conditions, some typical hacks could be implemented:

• a wait loop for the socket
• manual delay (sleep time) between step 4 and step 5
• some kind of poll mechanism
• conntrackd somehow notifies of UNIX socket being opened

After a bit of research, I found that the last point could be implemented very easily using libsystemd, so the daemon inform of its internal state to systemd [4].

The solution is elegant, simple and offers more direct benefits:

• systemd watchdog support
• no guess games with the PID of the daemon
• shutdown detection by systemd (so if the daemon was killed with 'conntrackd -k', systemd detects it)
• we get the service 'status' check (missing in sysvinit)

[0] https://lists.debian.org/debian-devel/2016/08/msg00448.html
[1] https://tracker.debian.org/pkg/conntrack-tools
[2] https://lists.debian.org/debian-devel/2016/08/msg00456.html
[3] https://sources.debian.net/src/systemd/231-4/debian/systemd.NEWS/
[4] http://git.netfilter.org/conntrack-tools/tree/src/systemd.c

I have been delighted with git for several years now. It's a very powerful tool and I use it every day.
I try to use git in all possible tasks: bind servers, configurations, firewalls, and other personal stuff.

However, there has been always a thing in my git-TODO: a blog managed with git.

After a bit of searching, I found an interesting technology: jekyllrb hosted at github pages. Jekyll looked easy to manage and easy to learn for a newbie like me.
There are some very good looking blogs out there using this combination, for example: https://rsms.me/

But I was lazy to migrate this 'ral-arturo' blog from blogger to jekyll, so I decided to create a new blog from scratch.

This time, the new blog in written in Spanish and is about adventures, nature, travels and outdoor sports.
Perhaps you noticed this article about the Mulhacen mountain (BTW, we did it! :-))
The new blog is called alfabravo.org,

I like the workflow with git & jekyll & github:

• clone the repository
• write a new post in markdown
• read it and correct it locally with 'jekyll serve'
• commit and push to github
• done!

Who knows, perhaps this 'ral-arturo' blog ends being migrated to the new system as well.

Before I started contributing to the iptables package back in December 2015 it suffered from a numbers of problems so the package was clearly in very bad shape.

One of the first problems was the lack of VCS for the package, no git, not even svn. Of course this was easy to solve and I did it straight away importing iptables 1.4.21-2 into a git repository.

The 1.4.21-2 version was dated in May 2014. This is a lot of time for a package which is active upstream and which is installed in almost all the Debian systems out there.

The number of Debian bugs opened for the package was simply huge, and I cleaned the bugtracker as reported in the blogpost "Current status of iptables & nftables in Debian".

Netfilter project upstream released version 1.6.0 which includes the nftables-compat stuff (iptables on top of the nftables kernel engine, and also the translation tools). Adding this was not an easy task given the overall state of the package.

Also, users were asking for normal things, like Multi-Arch support (see #776041). Adding Multi-Arch support to iptables has been my personal packaging nightmare for a couple of months.

Michael Biebl, who is systemd Debian maintainer, required some changes in the iptables package as well (see #787480). This change asked for a package split to libiptc, libip4tc, libip6tc and libxtables-dev (instead of iptables-dev).
This binary package split was also required for a proper Multi-Arch support.

The situation has been clearly a huge challenge for me,: I made a lot of mistakes, I discovered how little I know about complex packaging, and I had to learn a lot about several stuff.
Probably some experts and experienced DD's could have solved the situation with more solvency, but at the end I enjoyed all the work and the learning :-)

All this changes required me about 60 commits to complete, in several uploads. The last one is 1.6.0-3 which is now in the NEW queue.

I would like to note that both Ana Guerrero and Michael Biebl invested a lot of time in reviewing and sponsoring the packages. Thanks you!

There are still work to be done, of course.

The 26th of April I gave a talk in the University of Seville (ETSII) about contributing to FLOS software, focusing in the main projects I contribute to: Debian and Netfilter.

The talk was hosted by SUGUS, which is the university local group of FLOSS users.
The public were other students of the university, all of them young (like me), so the talk was very relaxed and formalities-free :-)

I talked my experiences in contributing to FLOSS, type of projects, how to start and how I integrate this with my full-time job.

Here is a video recording of the talk (in spanish):



I gave a similar talk some months ago to the students of the IES Gonzalo Nazareno.

Good news. The Debian Continuous Integration system is just awesome.

If a developer of a package prepares and declares tests for a given package, this CI system will trigger these test from time to time.
These tests are intended to check packages 'as installed', i.e, test what the end user is going to use in a final system.

The CI system is being improved, and now it supports 2 architectures: amd64 and arm64. Also, it now implements LXC as a backend, so the level of isolation available to run tests is very good, allowing us developers to launch even more elaborated tests.

This is the case of the HA stack (pacemaker, corosync, crmsh...), and the good news is that Debian is now continuously testing these packages.

At the time of this blog post, these are the tests:

• corosync: start the system service (the daemon) with the default Debian configuration
• pacemaker: start the system services (corosync and pacemaker daemons) with the default Debian configuration.
• crmsh: start the system services (corosync, pacemaker) and then add a basic resource (a virtual IP address) and do some tests (start the resource, stop, delete...)

This week I've entered the Debian NM process to move from Debian Maintainer (DM) to Debian Developer (DD).

But, what have I been doing for Debian lastly?

I've been DM for the last year, after a couple of years maintaining packages with sponsors.

Since 2015 until this time of the 2016 year, I've done roughly 33 package uploads, opened 67 bugs and contributed to many others. I maintain and co-maintain now 9 packages, most of them Netfilter-related.

This is a graph of bugs assigned to my packages in the last natural year:


I was supported to start the process by Anibal Monsalve, and Vincent Cheng intermediately become by advocate.

The duration of the NM process can vary depending on a number of factors, from a couple of months to a couple of years.

BTW, I got my opened bug statistics with this small script: deb_bugs_years.sh

I have been in some adventures with a group of friends for a couple of years now. We call ourselves Los Extraviaos (a quick translation to english is perhaps The Wanderers).

We like nature adventures. During summer we use to do water adventures (like rivers trekking, waterfall climbing, snorkeling, canyoning, rafting, kayaking and so on). During winter and spring, we use to do trekking, hiking and mountaineering (low altitudes, keep reading).

For this sport season, one of our main milestones is to climb the second most prominent mountain in Spain: Mulhacen, with 3.479 m over sea level, during summer (June).
From an alpinist point of view, this isn't a very big deal, since most of the mountain's snow and ice is completely melted and the altitude is not that high.
However, from our amateur mountaineering point of view we will be taking a lot of kilometres to walk and a lot of elevation gain uphill (almost 1.600 m), which is in fact a thing to take into account.
Anyway, Mulhacen is considered 'high mountaineering' and all cautions should be taken both during preparation/training and during the climbing of the mountain itself.

To train our bodies and minds we are climbing lower mountains. We have climbed 3 or 4 already, and will continue to climb more in upcoming moths until we go to Mulhacen.
Also, it's important to climb mountains in different weather conditions. We need to train how to overcome wind, snow, storm, cold, night situations. The way we learn most is facing new, challenging situations.

We started by going to the summit of 'El Aljibe', 1.094 m over sea level, with about 500 m elevation gain uphill during 13 km.
This time, the weather was very windy. A video of the summit moment:


A pic of the group:


Next was the 'Torrecilla' peak. The summit is at 1.919 m over sea level, with about 900 m elevation gain uphill during 15 km.
This time we faced a snowy trekking.
Here a music video of that day:


The Torrecilla peak is in fact challenging with snow, so we went a second time, with even more snow and wind:


This second time we faced winds of 70km/h which, due to wind-chill, resulted in a very cold day.

We also went to Sierra de Grazalema Natural Park, in a hard trekking under snowfall:


This time we walked about 15 km with about 500m elevation gain uphill, while enjoying this kind of environment:


What's next: more mountains! We plan to reach 2.069 m over sea level next week in 'La Maroma' and keep doing steep trekking in upcoming months until we go in June to Mulhacen.

It should be very funny to do some FLOSS contribution from the summit of a mountain. Do you know of someone who did that?

I would like to give an overview of what is the current status of iptables & nftables in Debian.
Some information contained in this article is not new, this post is about what happened to iptables & nftables in the last 3 months, focusing on the integration with Debian.
versionsBy the time of this article, upstream versions are:

• iptables 1.6.0
• nftables 0.5
• libnftnl 1.0.5

iptables maintenanceready for stable?

Given the HA stack is now in very good shape in Debian stretch [testing by now] we can start playing a bit with these tools.

There are 2 main points in doing so now:

1. reporting bugs
2. systemd integration

Packages
Basic configurationYou will need to edit the /etc/corosync/corosync.conf file:


Note that if you choose the proper bindnetaddr directive, you can use the exact same file for all the nodes (see corosync.conf(5))

System, daemons, servicesYou may want to check that the corosync and pacemaker services are auto-started at boot time by systemd.
Do a reboot and check it:


Also, check that no firewall blocks the communication between both nodes.

Now, the status of the cluster should show both nodes working together (with no resources):


ResourcesNow, you can start playing with the cluster resources. Below is an example of a virtual IPv6 address:

$ sudo crm configure primitive test ocf:heartbeat:IPv6addr params ipv6addr="fe00::200" cidr_netmask="64" nic="eth0"

Which should give this cluster status:


Congratulations, now you have a working HA cluster with a virtual IP address, using an active/backup approach.

Please, report any bug you may find.

Great news! The HA stack has been finally updated and you can find now both pacemaker & corosync in Debian stretch.

This is thanks to the hard work of some people, specially Christoph Berg, Ferenc W gner, Martin Loschwitz and others.

By the time of this blogpost, in testing (stretch) you have:

• pacemaker 1.1.14-1
• corosync 2.3.5-3
• crmsh 2.2.0-1

• pcs 0.9.148-1

what to do now